As it is generally known, application server computer systems are often used to provide various specific types of services to multiple users. The users of application servers typically consume the provided services through client software executing on client computers. The client computers interact with the application servers over a communication network such as the Internet. Existing systems for providing services from application servers have significant shortcomings, as illustrated by the following examples.
Electronic commerce (“e-commerce”) is one example of a service provided by application servers to end users. E-commerce typically involves doing business via the World Wide Web (“Web”), and generally enables online purchasing of goods and/or services. Well known existing e-commerce systems include eBay®, Amazon.com, and MSN Hotmail. E-commerce Web sites must support large numbers of customers simultaneously. For example, use of a hypothetical e-commerce site could grow to an average of 250,000 concurrent users at any given time. A company providing such a site might use a five node cluster of application server computer systems to support these customers and their interactions with the site, for an average of 50,000 users per node. The company may have performed prototyping and system performance measuring before the servers went into service showing a significant reduction in quality of service when there are over 55,000 users per node. Accordingly, the company might like to keep the number of users on each node equal to or less than this threshold value so that they can assure a positive end user experience. However, a catastrophic failure might occur at some point, in which one of the five nodes suffer an unrecoverable error. At such a time, 20% of the users (50,000) have to be dealt with in some failover capacity. However, the performance metrics show that each of the remaining four nodes could handle only an additional 5,000 users without a significant degradation in system performance. These circumstances would allow only 20,000 users to failover gracefully, leaving an additional 30,000 users who must have their sessions terminated. The customers currently using the e-commerce site at the time of the failure, and that might accordingly be affected by the failure, could have a variety of different attributes. It would be desirable to consider these user attributes when determining how the affected users are treated by the application servers as the per server demand increases because of the failure.
For example, a first user with an active user session at the time of the increased server demand might log onto the e-commerce site often, and average a $5 purchase per session. Another active user might be an established customer averaging a $20 purchase per session. Still another user might be a new customer without a purchase history, who was in the middle of attempting a first purchase at the site at the time of the failure. Other users might be customers that log in to check prices and compare deals, but rarely make purchases. Unfortunately, existing technology does not take into consideration such differences between currently active users when determining which users to failover gracefully, and which to kick off a system in the face of a server failure or other events causing an increase in server demand beyond a predetermined threshold.
In another example of the shortcomings of existing systems, an information technology (“IT”) department head for a large cable television corporation may have responsibility for an externally available portal Web site that attracts many visitors each month. The portal provides multiple access levels for end users:
1. Anonymous access—Anonymous access is used by customers (or potential customers) to find out about products, services, information, FAQ's, etc. about the company.
2. Silver access—Silver access is used by regular account holders that have purchased a single product or service. Silver account holders have access to all of the information (portlets) that Anonymous access users have access to, and additionally have the ability to view and pay their bill online, have customized channel listings, and change their programming options or order a pay-per-view movie.
3. Gold access—Gold access is for premium account holders that have purchased multiple products/services into a combined package. Gold access customers have access to all of the information (portlets) that Silver access users have, plus they have the ability to watch live events online, view information on exclusive content before it is televised, and also have the ability to download/replay certain video clips of an event that they may have missed.
The IT department head may be informed that customer satisfaction has been low for Silver access customers, but has been quite acceptable for the Gold access customers. As part of an effort to increase customer satisfaction for the Silver access account holders, the department head would accordingly like to offer the same content to the Silver access customers as provided to Gold access customers, but without downgrading the performance/satisfaction of the Gold access customers. Unfortunately, funds maybe insufficient to purchase the new server systems required to fully support Gold level services for the Silver access customers at all times. Accordingly, the department head may desire to offer additional services to the Silver access users with the current server configuration at times when server demand is within acceptable levels. Existing systems also do no provide the ability to do this.
Both the above examples demonstrate a need to dynamically change application server behavior for current user sessions, based on user classification and/or group membership and responsive to a current level of server demand. When a server's resource availability and/or performance are within a predefined, acceptable level, then it would be desirable for the system to operate as usual, for example by distributing access evenly across different users/groups. But when a server's predefined resource availability and/or performance threshold is reached, for example due to stress under load, failure, etc., then a privileged user/group type should have priority on system resources. In the above IT department example, such a system would be desirable since it could ensure that the Gold access members have the required resources, for example on a Portal Server or other type of Application Server, even when server demand is high. When the demand came is within acceptable levels, it would be desirable to be able change access control lists (ACLs) or the like to allow Silver access users to access Gold level content. Such a system enable the content provider to enhance the experience of Silver access customers, while still preserving the existing performance experience for Gold access customers.
Some existing packet forwarding systems provide service monitoring in conjunction with a policy server that makes decisions on where to route packets based on server congestion. However, such systems fail to describe or suggest operating on an individual user or group level, and/or making intelligent decisions at the individual user/group level for individual user sessions with an application server. Moreover, such systems do not dynamically change a current user's application session behavior based on application server congestion, and are instead concerned with overloaded devices such as routers, switches, etc., therefore not taking into account individual users on a specific application server.
Other existing systems are rule based systems for allowing or denying access to network services. Such systems may include techniques for associating a policy to a network resource, grouping resources/policies, mapping a username to an Internet Protocol (IP) address, and providing dynamically mapped user and hostnames with network devices. Although such systems are sometimes rule based, whereby network policies can be applied to users and groups, they do not describe or suggest monitoring of application server resources/performance as an input to changing user application session behavior. Instead, these existing systems only describe mapping users/groups to network resource policies, without regard to server demand or user application session behavior provided by application servers.
Various session monitors exist that track user actions during a session, and that track performance data, but these monitors do not provide or suggest any mechanism by which this data would be used to alter the behavior of a particular user's application session during a failover scenario, and/or when the overall server response is no longer meeting predefined performance characteristics. Likewise, some previous applications may include performance monitoring of individual portlets on a portal server, and can determine if an individual application (portlet) on the server is causing performance problems, but they do not attempt to dynamically change user/group session behavior during any given action. Instead, such systems may notify an administrator that there is a problem with the server and which application(s) is the culprit for the problem.
For the above reasons and others, it would be desirable to have a new method and system that dynamically changes session behavior for a user or group of users in response to server demand.